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REMARKS 

The Examiner is requested to approve the accompanying replacement drawing. The 
changes to the drawings are to change the location of Figures 5a and 5b as described in the 
Amendments to the Drawings section. 

Claims 1- 32 are pending in this application, have been rejected, and are at issue herein. 
Reconsideration of claims 1-32 and indication of the allowance thereof are respectfully solicited. 

Claim 1 has been amended to point out with greater particularity what the applicant 
regards as his invention. Specifically, claim 1 has been amended to point out that the priority 
of the notification is based upon a user's specified priority. Support for this amendment lies 
in the originally filed specification. For example, on page 19 lines 10 to 13, the specification 
states that the user specifies the priority of how notifications are rendered. The priority includes 
which notification classes have priority over other notification classes and how often the 
notification component of the invention notifies the user. No new matter has been added by this 
amendment. Claim 15 has also been amended to point out with greater particularity that the 
priority of the notification is based upon a user's specified priority c 

35 USC §102 Rejections 

The Examiner has rejected claims 1-8, 10-21, 23-25, 30, and 32 under 35 U.S.C. 102(e) 
as anticipated by Nguyen et al. (U.S. Patent No. 6,412,021). This ground of rejection is believed 
overcome by the above amendments to Claims 1 and 15. Reconsideration of this ground of 
rejection and allowance of Claims 1-8, 10-21, 23-25, 30, and 32 in view of the foregoing 
amendments and the following remarks are respectfully solicited. 

Claims 1 and 15 have been amended to point out that the priority is based upon a 
priority specified by the user. As explained in the present specification, the user specifies the 
priority of how notifications are rendered. The priorities that are specified include which 
notification classifications have priority over other notification classifications and how often 
the notification component should notify the user. The Examiner states that the event of 
Nguyen et al. is assigned a priority when the event is placed on the event queue because the 
events in queue are processed in a first-in-first-out sequence. This queued priority is not 
based upon a user's specified priority. Nguyen et al. does not teach or suggest assigning a 
priority to assign the notification based on the user's specified priority or rendering the 
notification in accordance with the priority. Therefore, Nguyen et al. does not teach all of the 
elements of claims 1 and 15. 
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Furthermore, Nguyen et al. teaches receiving an event and determining an appropriate 
response to the event. It is respectfully submitted that receiving an event and determining an 
appropriate response to the event is not the same as receiving a notification to provide to a 
user and rendering the notification because the event is not received to provide to a user. In 
view of the foregoing, it is respectfully requested that the Examiner withdraw the rejection of 
claims 1 and 15. 

Claims 2-8, and 10-14 depend from claim 1 and are believed to be patentable for the 
same reasons set forth above for claim 1. Claims 16-21, 23-25, 30, and 32 depend from 
claim 15 and are believed to be patentable for the same reasons set forth above for claim 15. 

With respect to claim 5, the Examiner states that Nguyen teaches XML-based 
notification at column 10, lines 47-67; column 8 lines 15-27. Nguyen has been reviewed and 
Nguyen teaches the use of HTML, which stands for Hypertext Markup Language. XML 
stands for extensible Markup Language. XML is defined as a subset of SGML, which stands 
for Standard Generalized Markup Language. SGML was developed for large scale 
applications, aircraft maintenance or power plant documentation, and intended to be 
maintained over the long term. It is not the same as HTML. The Examiner may believe that ' 
XML is the same as HTML, but it is not. The reason why XML seems to be so similar to 
HTML lies in the fact that HTML is defined as a subset of SGML. The most salient 
difference between HTML and XML is that HTML describes presentation and XML 
describes content. An HTML document rendered in a web browser is human readable. XML 
is aimed toward being both human and machine readable. XML itself is not a single markup 
language: it's a metalanguage to let you design your own markup language. A regular 
markup language such as HTML defines a way to describe information in a certain class of 
documents. XML lets you define your own customized markup languages for many classes of 
document. Therefore, it is respectfully submitted that Nguyen does not teach or suggest an 
XML-based notification. 

With respect to claims 7 and 24, the Examiner states that Nguyen teaches an alpha- 
blended display and a transient display. The Examiner is directed to Figures 5a and 5b of the 
present specification, which shows a transient display and an alpha-blended display, 
respectively. It can be seen that an alpha-blended display is a display in which the levels of 
opacity or transparency is selected so that the image behind the alpha-blended display is 
partially visible and the image behind a transparent display is completely visible. Nguyen 
teaches a flashing glyph and a fixed glyph on the button icon. A flashing glyph and a 
fixed glyph are not an alpha-blended display or a transient display. Therefore, it is 
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respectfully submitted that Nguyen does not teach or suggest an alpha-blended display or a 
transient display. 

With respect to claim 1 1, the queue is arranged to the priority of the notification. This 
means that the priority is known prior to placing the notification in the queue. Nguyen 
teaches queuing a notification in a first-in-first-out sequence. The priority of such a queue 
does not arrange the queue according to the priority of the notification since the priority is not 
known until the notification has been queued as other notifications can be queued before the 
notification has been queued. Therefore, it is respectfully submitted that Nguyen does not 
teach or suggest arranging a queue according to the priority of the notification. 

With respect to claim 12, the Examiner states that Nguyen teaches flushing a queue 
because an event is removed from the event queue when the event is processed. The 
applicants respectfully disagree. Flushing a queue means that all events in the queue are 
removed from the queue without processing the events in the queue. Flushing a queue does 
not mean removing an event from the queue when the event is processed. Therefore, it is 
respectfully submitted that Nguyen does not teach or suggest flushing a queue 

With respect to claim 1 3, the Examiner states that the number of times the user is 
provided notification is based on the number of events in the queue. The applicants 
respectfully disagree. Claim 13 requires the step of determining the number of times a 
particular notification is provided to the user. The number of events in the queue does not 
determine the number of times that the user is provided a particular notification. Nguyen et 
al. has been reviewed and no teaching or suggestion could be found of determining a number 
of times the user is provided a notification. 

With respect to claims 14 and 17, the Examiner states that Nguyen teaches the 
elements of claim 14 and 17. Specifically, the Examiner states that column 4 lines 38-52 and 
column 12, lines 20-40 teaches checking a user preference list to see if the notification 
classification is listed in a list of selected of selected classifications selected by the user to 
indicate which notification the classifications the user wants to receive and rendering the 
notification if the notification class is listed in the list of selected classifications. The 
applicants respectfully disagree. Column 4 lines 38-52 of Nguyen teach checking a 
configuration button to see what button icons should be displayed in a selection bar. As 
described in the instant specification, a notification classification is a category of 
notifications, which includes a contact classification, a financial classification, an e-mail 
classification, and an audio classification. It is respectfully submitted that a button icon is not 
a notification classification as defined in the instant specification and required by claim 14 
rendering the notification in accordance with a user preference as required by claim 17. 
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Therefore, it is respectfully submitted that Nguyen does not teach or suggest checking a user 
preference list to see if the notification classification is listed in a list of selected 
classifications selected by the user to indicate which notification the classifications the user 
wants to receive and rendering the notification if the notification class is listed in the list of 
selected classifications. 

With respect to claim 18, the Examiner states that column 12, lines 20-40 of Nguyen 
teach determining if the classification enable is enabled for the notification classification. 
Column 12, lines 20-40 of Nguyen teach that the event ID is used to determine an appropriate 
response to the event. The response entails one or more forms of user notification, including 
changing a button icon in a selection bar, setting a fixed or flashing glyph on the button icon, 
displaying a message in a dialog box, or playing an audio clip. The above teaches that the 
user is always notified of an event. Claim 18, on the other hand, requires that the 
classification enable of a notification classification be enabled in order for the notification to 
be rendered. This means that the user is not always provided the notification. Therefore, it is 
respectfully submitted that Nguyen does not teach or suggest a classification enable of a 
notification classification be:enabled in order for the notification to be rendered. It is : 
respectfully submitted that Nguyen teaches away from requiring that a classification enable 
of a notification classification be enabled in order for the notification to be rendered. 

With respect to claim 21, the Examiner states that Nguyen at column 12, lines 1-12 
teaches sending a pre-notification notification prior to rendering the notification if the 
notification is an audio notification. As described in the instant application at page 16, line 
23 to page 17, line 5, and as required by claim 21, the pre-notification alert is sent to a user. 
This alerts the user that an audio notification is arriving so that the user does not miss or 
misinterpret the first words of the audio notification. 

With respect to claim 30, the Examiner states that column 7, lines 63-67 of Nguyen 
teaches performing at least one action if the notification is selected by a user selection device. 
Nguyen teaches at column 7, lines 63-67 that a user presses an associated button icon in the 
selection bar when the user wishes to use the enterprise application represented by the 
associated button icon. The action of pressing the associated button icon triggers a mouse 
event that results in the loading and display of the selected application. The associated button 
icon is not a notification. It is merely a representation of a program. Therefore, it is 
respectfully submitted that Nguyen does not teach or suggest performing an action if the 
notification is selected by a user. 

With respect to claim 32, the Examiner states that Nguyen teaches a long version (a 
message in a dialog box) and a short version (method to display updated clock images on the 
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associated button icon) and points to column 13, lines 35-50 of Nguyen for support. The 
Examiner is directed to page 18, line 17 to page 19, line 9 of the present specification. A 
long version and a short version is a version of the same notification. For example, the long 
version of a notification could be "Microsoft up 2 at 82 on increased volume" and a short 
version of the notification could be "Microsoft up 2 at 82." The rendering styles the 
Examiner is referring to in Nguyen do not teach or suggest a long version and a short version 
of a notification. 

In view of the foregoing, it is respectfully requested that the Examiner withdraw the 
rejection of claims 2-8, 10-14, 16-21, 23-25, 30, and 32. 

35 USC §103 Rejections 

To establish a prima facie case of obviousness, there must be some suggestion or 
motivation, either in the references themselves or in the knowledge generally available to one 
skilled in the art, to modify the reference or combine teachings. There must be a reasonable 
expectation of success and the prior art references must teach or suggest all of the claim 
limitations. See MPEP 2142. Conclusory. statements cannot be relied on when dealing with, 
particular combinations of prior art and specific claims. The rationale for combining 
references must be put forth. In re Lee, 61 USPQ2 d 1430, 1433. The Examiner can satisfy 
the burden of showing obviousness of the combination "only by showing some objective 
teaching in the prior art or that knowledge generally available to one of ordinary skill in the 
art would lead that individual to combine the relevant teachings of the references". The 
Applicants respectfully submit that the Examiner has made conclusory statements in the §103 
rejections and has put forth no rationale as to why one of ordinary skill in the art would 
combine the references. The Examiner has only stated what the Examiner believes the 
references teach and that it would be obvious to combine the references based on what the 
patent combined with Nguyen teaches. The Applicants respectfully submit that a prima facie 
case of obviousness has not been made. 

The Examiner has rejected claim 9 under 35 USC 103 as being unpatentable over 
Nguyen in view of U.S. Patent No. 6,144,942 to Ruckdashel. Claim 9 is believed to be 
patentable for the reasons set forth above and for claim 1 . Therefore, it is respectfully 
requested that the rejection of claim 9 be withdrawn. 

The Examiner has rejected claim 22 under 35 USC 103 as being unpatentable over 
Nguyen in view of U.S. Patent No. 6,501,739 to Cohen. Claim 22 is believed to be 
patentable for the reasons set forth above and for claim 15. Therefore, it is respectfully 
requested that the rejection of claim 22 be withdrawn. 
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The Examiner has rejected claim 31 under 35 USC 103 as being unpatentable over 
Nguyen in view of U.S. Patent No. 6,424,357 to Frulla. Claim 31 is believed to be patentable 
for the reasons set forth above and for claim 15. Therefore, it is respectfully requested that 
the rejection of claim 31 be withdrawn. 

The Examiner has rejected claims 26-29 under 35 USC 103 as being unpatentable 
over Nguyen in view of U.S. Patent No. 5,950,21 1 to Shealy. Claims 26-29 are believed to 
be patentable for the same reasons set forth above and for claim 15. 

With respect to claim 27, Shealy teaches logging an event when a queue is flushed. 
Claim 27 requires flushing read items from the history that have been read by a user and 
flushing old items from the history based upon user preferences. It is respectfully submitted 
that logging an event when a queue is flushed or flushing messages in a given priority is not 
the same as and does not suggest flushing items from a history after they have been read or 
flushing old items determined from the user preference. Therefore, neither Nguyen or 
Shealy, singly or in combination, teach or suggest all of the limitations of claim 27. 

With respect to claims 28, claim 28 depends from claim 27 and is believed to be 
patentable for the same reasons put forth above for claim 27. Furthermore, claim 28 requires 
that items. in the history be displayed in accordance with the user preference. Shealy teaches 
using the utility 90 to obtain history log information in the form of a report. No teaching 
could be found of displaying items in the report in accordance with a user preference. 
Therefore, neither Nguyen nor Shealy, singly or in combination, teach or suggest all of the 
limitations of claim 27. 

With respect to claim 29, it requires the steps of displaying the history and performing 
at least one action if a notification in the history is selected by a user selection device. Shealy 
teaches using the utility to obtain history information in the form of a report. Shealy also 
teaches using the utility to configure a device driver and to process collected information. 
Configuring a device driver and collecting information are performed without selecting a 
notification in the report of Shealy. No teaching or suggestion could be found in either 
Nguyen or Shealy of performing an action if a notification in the history is selected by a user 
selection device. 

Therefore, in view of the foregoing, it is respectfully requested that the rejection of 
claims 26-29 be withdrawn. 

Conclusion 

The application is considered in good and proper form for allowance, and the 
Examiner is respectfully requested to pass this application to issue. If, in the opinion of the 
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Examiner, a telephone conference would expedite the prosecution of the subject application, 
the Examiner is invited to call the undersigned attorney. 



Respectfully submitted, 

Kevin L. Wingate, Reg. m. 38662 
LEYDIG, VOIT & MAYER, LTD. 
6815 Weaver Road, Suite 300 
Rockford, Illinois 611 14-8018 
(815) 963-7661 (telephone) 
(815) 963-7664 (facsimile) 

Date: September 26, 2003 
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